home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 5482 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-05  |  2.0 KB  |  42 lines
  1. On Sat, 24 Feb 1996, Geoffrey Welsh wrote:
  2.  
  3. > In article <4gbq18$thu@navajo.gate.net>, dhaire@gate.net (doug haire) wrote:
  4. > >Geoffrey Welsh (insystem@pathcom.com) wrote:
  5. > >: In article <4ft8gp$4va@freenet3.scri.fsu.edu>,
  6. > >:    tbordia@freenet.scri.fsu.edu (Luis Montenegro) wrote:
  7. > >: >Hello.  Could someone give me any idea of what this mean?  I know it 
  8. > >: >tells me that there is a problem either on the line or the modem.
  9. > >: >
  10. > >: >CONNECT 14400/V32/NONE
  11. > >: >~_~?~y~y~?~~?~?z__O_?>~??~_?_~?z~?z~??~?~y_~?~_>~?~y?~~?z~?~_~?~?~?
  12. > >: 
  13. > >: I'd guess neither, though it might be your serial port speed (make sure 
  14. > that 
  15. > >: it's 'locked'... err, that AT&B1< I think).
  16. > >
  17. > >Take a closer look... "14400/V32/NONE" The "NONE" means NO error 
  18. > >correction was negotiated resulting in an unstable connection resulting 
  19. > >in that garbage you see below theCONNECT message.
  20. > >
  21. > >Looks pretty clear to me about what happened and which end is at fault is 
  22. > >still an issue.
  23. > 
  24. > The fact that one end reported no error correction doesn't necessarily mean 
  25. > that the whole connection is hopelessly fouled... quite often I see CONNECT 
  26. > [...]/NONE messages on the console of a two-line BBS, and the user just 
  27. > proceeds to log in.  Also, I have seen similar junk on a Trumpet login screen 
  28. > following a CONNECT [...]/LAPM/V43BIS message, leading me to conclude that the 
  29. > ISP end hasn't dicontinued the SLIP/PPP stream for a login.
  30.  
  31. Simply because a user continues to login does not change the fact that 
  32. there is *no* error correction. I often have users login after such 
  33. connections. Since my lines are pretty clean, they have very little 
  34. trouble except for their transfer rates which stay *below* 1400 cps.
  35. I have even seen one 26400 connect with no error correction which managed 
  36. to stay connected.
  37.  
  38. You should *never* see line garbage on a LAPM connection. Never. I don't 
  39. think you saw that at all. What you may have seen was "buffer barf" from 
  40. a previous connection (though even that is highly doubtful).
  41.  
  42.